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ABSTRACT 


In  this  thesis,  the  sealability  issues  of  Simple  Network  Management  Protoeol 
(SNMP)  in  optical  network  management  are  explored.  It  is  important  to  understand  the 
effect  of  varying  the  number  of  nodes,  the  request  inter-arrival  times  and  the  polling  in¬ 
terval  on  the  performance  of  SNMP  and  number  of  nodes  that  can  be  effectively  man¬ 
aged.  The  current  study  explored  the  effect  of  varying  these  parameters  in  a  controlled 
test  environment  using  the  OPNET  simulation  package.  In  addition,  traffic  analysis  was 
performed  on  measured  SNMP  traffic  and  statistics  were  developed  from  the  traffic 
analysis.  With  this  understanding  of  SNMP  traffic,  an  SNMPvl  model  was  defined  and 
integrated  into  an  OPNET  network  model  to  study  the  performance  of  SNMP.  The  simu¬ 
lation  results  obtained  were  useful  in  providing  needed  insight  into  the  allowable  number 
of  nodes  an  optical  network  management  system  can  effectively  manage. 
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EXECUTIVE  SUMMARY 


Optical  networks  are  in  a  period  of  transition  when  it  eomes  to  network  manage¬ 
ment  issues.  At  the  present  time,  optieal  network  management  is  still  a  young  diseipline 
and  eonsiderable  development  is  required  before  it  ean  be  deployed  to  manage  large  opti¬ 
eal  networks.  Introdueed  in  1988  to  provide  management  eapability  for  TCP/IP-based 
networks,  SNMP  rapidly  beeame  the  most  widely  used  standardized  network  manage¬ 
ment  tool.  SNMP  is  designed  aeeording  to  a  eentralized  network  management  paradigm 
eharaeterized  by  a  low  degree  of  flexibility  and  re-eonfigurability.  This  eentralized  ap- 
proaeh  is  known  to  present  severe  efficieney  and  sealability  limitations:  the  proeess  of 
data  eolleetion  and  analysis  typieally  involve  massive  transfers  of  management  data  eaus- 
ing  strain  on  network  throughput  and  proeessing  bottleneeks  at  the  manager  host.  The 
problems  of  effieieney  and  sealability  beeome  an  issue  with  the  inerease  of  management 
data. 

Until  now,  however,  no  exploration  had  been  eondueted  on  the  scalability  of 
SNMP.  It  is  important  to  understand  the  effect  of  varying  the  number  of  nodes,  the  re¬ 
quest  inter-arrival  times  and  the  polling  interval  on  the  performanee  of  SNMP  and  the 
number  of  nodes  that  eould  be  effeetively  managed.  Thus  the  eurrent  study  explores  the 
effeet  of  varying  these  parameters  in  a  eontrolled  test  environment  using  the  OPNET 
simulation  paekage.  The  main  thrust  of  the  study  was  to  explore  these  parameters  to  gain 
needed  insight  into  the  number  of  nodes  a  network  management  station  ean  effeetively 
manage  and  to  develop  notions  for  properly  speeifying  the  request  inter-arrival  time  to 
avoid  potential  proeessing  bottleneeks  and  network  eongestion. 

The  first  part  of  this  study  involved  performing  a  traffie  analysis  on  real,  opera¬ 
tional  SNMP  traffie.  Statisties  were  developed  from  the  traffie  analysis.  This  analysis  was 
neeessary  in  order  to  understand  traffie  parameters,  sueh  as  polling  interval,  request  inter¬ 
arrival  times,  request  packet  size,  ete.,  of  actual  SNMP  traffic.  With  this  understanding,  a 
SNMPvl  model  was  defined  and  integrated  into  an  OPNET  network  model  to  study  the 
sealability  issues  of  SNMP -based  polling.  Subsequently,  various  test  scenarios  were  gen¬ 
erated  and  simulated.  The  performanee  of  SNMP,  eonstrained  by  the  bandwidth  of  man- 


XV 


agement  channels  in  optical  networks,  was  studied  with  respect  to  the  effeet  of  varying 
the  number  of  nodes  and  request  inter-arrival  times,  and  obtaining  an  optimum  number  of 
nodes  for  a  speeified  polling  interval. 

In  exploring  the  effeet  of  varying  the  number  of  nodes  (from  50  to  250  nodes)  to 
be  managed  by  the  NMS,  it  was  determined  that  for  a  given  request  inter-arrival  time,  the 
link  utilization  and  link  throughput  would  inerease  with  an  inerease  in  the  number  of 
nodes  to  be  managed.  From  the  simulation  results,  potential  bottleneek  and  the  level  of 
eongestion  in  the  network  could  be  determined.  Hence,  the  allowable  number  of  nodes 
that  eould  be  effeetively  managed  by  a  NMS  at  a  speeifie  request  inter-arrival  time  eould 
be  determined  from  the  results  obtained. 

In  exploring  the  effeet  of  varying  the  request  inter-arrival  time  (from  2  p.  s  to 
5000  ps),  it  was  determined  that  for  a  given  number  of  nodes,  the  link  utilization  and  link 
throughput  would  deerease  for  an  inerease  in  request  inter-arrival  time.  From  the  simula¬ 
tion  results,  given  the  number  of  nodes  to  be  managed,  appropriate  request  inter-arrival 
time  eould  be  determined. 

Additionally,  for  a  given  polling  interval,  results  were  obtained  on  determining 
the  optimum  number  of  nodes  that  a  NMS  ean  effeetively  manage  for  different  request 
inter-arrival  time  without  any  signifieant  bottleneek  or  network  eongestion.  From  this 
analysis,  the  “bottleneek  zone”  and  “non-eongestion  zone”  were  defined.  In  the  “bottle¬ 
neek  zone”,  the  number  of  nodes  that  eould  be  managed  was  signifieantly  lower  than 
those  in  the  “non-eongestion  zone”.  However,  in  the  “non-eongestion  zone”  the  number 
of  nodes  that  eould  be  managed  was  limited  by  the  polling  interval. 
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I.  INTRODUCTION 


A.  MOTIVATION 

Networks  have  grown  from  the  eonneetion  of  a  few  eomputer  systems  loeated  in 
the  same  offiee  using  a  small  number  of  simple  protoeols  to  the  intereonneetion  of  sev¬ 
eral  widely  dispersed  and  highly  eomplex  eomputing  faeilities,  eommunieating  with  a 
mixture  of  protoeols.  This  growth  has  made  network  management  an  essential  and  eriti- 
eal  funetion.  To  maintain  the  network,  network  managers  must  eontrol  the  operation  of 
eaeh  attaehed  eomponent.  The  eombination  of  network  size,  equipment  eomplexity  and 
number  of  protoeols  would  make  this  nearly  an  impossible  task  if  eaeh  deviee  had  to  be 
eonfigured  manually  [1].  While  management  funetions  are  now  built  into  the  various  net¬ 
work  elements,  these  must  be  interoperable  with  the  management  systems  used  within  the 
network  in  order  to  be  useful.  Additionally,  the  reeurring  eosts  assoeiated  with  the 
management  of  a  large  network  ean  be  mueh  higher  than  the  aequisition  eosts  of  the 
equipment  [2]. 

Network  management  in  SONET/SDH  (Synehronous  Optieal  Network  /  Synehro- 
nous  Digital  Hierarehy)  networks  is  in  a  period  of  transition.  For  a  number  of  years,  the 
International  Standard  Organization  (ISO)  and  International  Teleeommunieation  Union 
Teleeommunieation  Standardization  Seetor  (ITU-T)  have  been  working  to  develop  sev¬ 
eral  open  systems  intereonneetion  (OSI)  network  management  standards.  The  proposed 
standards  are  based  on  the  eommon  management  information  serviee  element  (CMISE), 
whieh  defines  both  the  network  management  applieations  and  the  eommon  management 
information  protoeol  (CMIP).  However,  when  SONET  was  deployed,  neither  CMISE 
nor  CMIP  had  suffieient  maturity  to  be  integrated  into  produetion  equipment  and  net¬ 
works  due  to  their  eomplexity  [3]. 

In  the  mid-1980s,  the  simple  network  management  protoeol  (SNMP)  was  devel¬ 
oped  by  Internet  Engineering  Task  Foree  (IETF)  to  provide  simple  and  effeetive  man¬ 
agement  of  EAN-based  internetworking  produets  sueh  as  bridges  and  routers.  While 
SNMP  eentralizes  and  reduees  the  eomplexity  of  managing  eommon  network  resourees, 
SNMP  provides  the  flexibility  to  manage  vendor-speeifie  information  and  eonfigurations. 
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SNMP  has  continued  to  evolve  and  is  eurrently  supported  by  almost  every  enterprise 
network  equipment  manufacturer  worldwide  [1,4].  Due  to  its  ease  of  implementation  and 
simplieity,  SNMP  is  now  widely  used  as  a  network  management  standard. 


B,  OBJECTIVE  OF  THESIS 

The  primary  objective  of  this  thesis  was  to  study  the  performance  of  the  SNMP  in 
optical  networks  and  to  earry  out  an  analysis  on  its  performance  using  an  Optimized 
Network  Engineering  Tool  (OPNET)  simulation.  In  particular,  we  looked  into  the  seal- 
ability  of  SNMP  and  the  performanee  of  the  SNMP  operations.  We  explored  the  effeet  of 
varying  the  number  of  nodes  to  be  managed,  as  well  as  the  effect  of  varying  the  request 
inter-arrival  time.  Additionally,  we  also  explored  the  effect  of  polling  interval  on  the  op¬ 
timum  number  of  deviees  that  a  network  management  system  (NMS)  can  effectively 
manage  using  SNMP.  The  main  thrust  of  the  study  was  to  explore  these  parameters  to 
gain  needed  insight  into  the  number  of  nodes  a  NMS  can  effectively  manage  and  to  prop¬ 
erly  speeily  the  request  inter-arrival  time  to  avoid  potential  bottleneck  and  network  con¬ 
gestion. 


C.  RELATED  WORK 

Over  the  last  few  years,  with  the  development  of  new  teehnologies  the  capacity  of 
optical  transport  networks  has  inereased  rapidly.  This  inerease  in  capacity  has  created  an 
issue  in  the  management  and  control  of  the  optieal  networks.  Performance-related  issues 
of  network  management,  sueh  as  effieiency,  scalability,  flexibility  and  re-eonfigurability, 
have  been  the  foeus  of  much  research.  Virtually  all  current  network  management  systems 
are  designed  using  a  eentralized  network  management  approaeh  [5].  There  is  also  a  mov¬ 
ing  trend  towards  distributed  network  management.  New  enabling  technologies,  such  as 
mobile  agents,  web-based  network  management  and  Java-based  network  management, 
have  been  developed  for  distributed  network  management  [6]. To  prove  the  commereial 
viability  of  optieal  network  management,  considerable  research  effort  will  be  required  in 
the  area  of  network  management  and  control  [7].  In  recent  years,  numerous  papers  on 
network  management  and  eontrol  have  been  published.  The  Multi-wavelength  Optieal 

Networking  (MONET)  program  [8],  mobile  agent  teehnology  in  network  management 
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[5,9]  and  enabling  technologies  for  distributed  network  management  [6]  are  some  of  the 
examples  on  research  work  done  in  the  area  of  network  management  and  control.  The 
MONET  program,  sponsored  by  the  Defense  Advanced  Research  Project  Agency 
(DARPA),  brought  together  resources  from  leading  telecommunication  companies  and 
several  government  agencies  to  develop  technologies  needed  for  a  high-capacity,  high- 
performance,  and  national-scale  optical  network  based  on  the  multi-wavelength  fiber¬ 
optic  technology  [8].  A  more  detailed  description  of  the  program  can  be  found  in  Refer¬ 
ence  [8]. 

D,  SUMMARY 

In  today’s  increasingly  expanding  optical  networks,  problems  of  scalability  and 
efficiency  become  an  issue  with  the  increase  of  management  data.  Hence,  in  order  to  en¬ 
sure  that  networks  are  properly  monitored  and  maintained,  there  is  a  need  to  study  and 
analyze  the  performance  of  the  commonly  used  network  management  protocol,  i.e., 
SNMP. 

The  thesis  is  organized  as  follows:  Chapter  II  presents  an  overview  on  the  man¬ 
agement  of  a  typical  optical  network.  It  also  provides  an  overview  on  the  in-band  data 
communication  channels,  which  are  used  to  transport  management  data  in  a  SONET  net¬ 
works.  Chapter  III  presents  the  comparisons  between  the  two  main  network  management 
protocols,  CMIP  and  SNMP,  along  with  their  respective  advantages  and  disadvantages. 
Chapter  IV  reviews  the  key  concepts  of  SNMP  and  describes  the  SNMP  protocol  opera¬ 
tions  and  message  formats  for  the  three  versions  of  SNMP.  Chapter  V  presents  the  traffic 
analysis  performed  on  measured  SNMP  traffic  and  the  statistics  developed  from  the  traf¬ 
fic  analysis.  Chapter  VI  describes  the  modeling  of  SNMP,  including  the  simulation  mod¬ 
ule,  simulation  parameters  and  test  scenarios  used  in  the  study.  It  also  discusses  the  simu¬ 
lation  results  obtained  with  respect  to  the  scalability  of  SNMP  in  a  typical  optical  net¬ 
work.  Chapter  VII  presents  a  summary  of  the  thesis  and  suggestions  for  follow-on  work. 
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II.  MANAGEMENT  OF  SONET  NETWORK 


A,  CHAPTER  OVERVIEW 

This  chapter  presents  an  overview  of  network  management  in  a  typieal  optieal 
network.  The  management  framework,  the  management  information  model  and  two  main 
network  management  protoeols  are  diseussed.  The  ehapter  also  reviews  the  data  eommu- 
nieation  ehannels  that  are  used  by  the  SONET  network  to  exehange  management  mes¬ 
sages  between  deviees. 


B,  MANAGEMENT  FRAMEWORK 

Besides  monitoring  and  eontrolling  network  elements  (NEs),  network  manage¬ 
ment  is  also  eoneerned  with  planning  and  aeeounting  for  the  use  of  NEs  and  their  aetivi- 
ties.  As  mentioned  earlier,  the  size  and  the  diversity  of  different  networks  led  to  eonsider- 
able  eomplexity  in  network  management  applieations.  Different  vendors  normally  devel¬ 
oped  their  own  proprietary  network  management  systems  (NMS).  Henee,  eaeh  NE  relied 
on  its  own  unique  NMS  for  management  purposes,  eausing  interoperability  issues  to  arise 
[10]. 

Figure  1  shows  the  implementation  of  key  network  management  functions  on  a 
typical  optical  network.  Typieally,  network  management  is  eentralized  and  may  involve 
multiple  management  systems  deployed  in  a  hierarehieal  manner  [2]. 
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Network  management  system 


Figure  1  Overview  of  network  management  functions  of  a  typical  optical  network 

(From  Ref.  [2].) 

Optical  line  terminals  (OLTs),  optical  add/drop  multiplexers  (OADMs),  optical 
amplifiers,  and  optical  crossconnects  (OXCs),  as  shown  in  Figure  1,  are  examples  of  NEs 
that  may  be  managed  in  the  network  by  the  NMS.  Each  NE  is  managed  by  its  element 
management  systems  (EMSs).  Communication  with  the  EMS  over  the  data  communica¬ 
tion  network  (DCN)  is  made  possible  by  a  built-in  agent  implemented  in  software.  While 
multiple  NEs  may  be  connected  to  an  EMS,  each  EMS  typically  manages  NEs  from  only 
one  vendor  and  can  view  only  one  NE  at  a  time.  Thus,  an  EMS  probably  will  not  have  a 
complete  view  of  the  entire  network.  A  fast  signaling  channel,  such  as  an  optical  supervi¬ 
sory  channel  (OSC),  as  shown  in  Figure  1,  is  also  required  for  the  exchange  of  real-time 
information  to  control  protection  switching  and  other  functions.  In  some  cases,  multiple 
EMSs  may  be  used  to  manage  the  overall  network.  In  larger  networks,  the  EMSs  com¬ 
municate  over  a  management  network  with  a  NMS,  also  known  as  an  operations  support 
system  (OSS).  The  NMS  has  a  complete  view  of  the  entire  network  and  may  manage  dif¬ 
ferent  types  of  NEs  from  various  vendors.  In  a  multi-tiered  management  hierarchy,  mul- 
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tiple  OSSs  may  be  used  to  perform  different  funetions,  sueh  as  fault  management  and 
provisioning  cireuits  [2], 


C.  DATA  COMMUNICATION  CHANNELS 

Each  SONET  frame  has  two  in-band  Data  Communication  Channels  (DCC), 
namely  the  Section  DCC  and  the  Eine  DCC.  Both  are  used  to  convey  network  manage¬ 
ment  messages  between  NMS  and  NEs.  Use  of  these  in-band  data  communication  chan¬ 
nels  preclude  the  requirement  for  expensive  out-of-band  management  communications 
[11]. 

Table  1  shows  the  section  and  line  overhead  in  the  transport  overhead  of  a 
SONET  Synchronous  Transport  Signal  “1”  (STS-1)  frame.  Three  bytes  in  the  section 
overhead,  bytes  Dl,  D2  and  D3,  form  the  Section  DCC,  a  192  kbps  channel  that  transfers 
operations,  administration,  maintenance,  and  provisioning  (OAM&P)  information  be¬ 
tween  section-terminating  equipment.  Nine  bytes  from  the  line  overhead,  bytes  D4 
through  D12,  form  the  Eine  DCC,  a  576  kbps  channel  for  OAM&P  (alarms,  control, 
maintenance,  remote  provisioning,  monitoring,  administration,  other  communication 
needs)  messages  between  line  entities  [11,12].  As  such  in  SONET,  the  DCCs  are  dedi¬ 
cated  for  the  exchange  of  management  traffic. 
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Section  Overhead 

A1 

A2 

JO/ZO 

B1 

El 

El 

D1 

D2 

D3 

HI 

H2 

H3 

B2 

K1 

K2 

Eine  Overhead 

D4 

D5 

D6 

D7 

D8 

D9 

DIO 

Dll 

D12 

Sl/Zl 

MO  or  M1/Z2 

E2 

Table  1  Transport  Overhead  in  a  SONET  STS-1  frame  (After  Ref.  [11].) 


D,  INFORMATION  MODEL 

An  information  model  (IM)  provides  a  standardized  way  of  representing  informa¬ 
tion  to  be  managed  by  eaeh  NE.  Implemented  in  software  within  the  NE,  EMS  and  NMS 
using  an  objeet-oriented  programming  language,  the  IM  speeifies  the  attributes,  aetivities, 
eharacteristies  and  external  behavior  of  the  network  deviee  to  be  managed  [2]. 


E,  MANAGEMENT  PROTOCOLS 

Most  network  management  systems  are  based  on  a  eentralized,  elient-server  rela¬ 
tionship  between  a  manager  (eentral  station  or  elient)  and  the  agents  (servers)  it  eontrols. 
When  the  manager  needs  to  read  or  retrieve  the  status  of  the  parameters  in  the  NE,  it  polls 
the  agent,  also  known  as  the  “get  operation”.  To  write  or  modify  values  in  the  NE,  the 
manager  will  use  the  “set  operation”.  The  agent  ean  also  send  notifieations  to  its  manager 
when  signifieant  events  oeeur.  Upon  deteeting  a  problem  within  the  NE,  the  agent  ean 
alert  its  manager  via  a  notifieation  message  or  an  alarm  if  the  eondition  is  serious.  These 
notifieations  are  also  known  as  “traps”  [2]. 

There  are  multiple  standards  relating  to  network  management  and  the  two  main 
network  management  protoeols,  SNMP  and  CMIP.  The  Internet  approaeh,  designed  to  be 
simple,  is  based  on  SNMP.  The  OSI  approaeh,  designed  to  provide  a  eommon,  flexible 
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and  robust  protocol  to  provide  solution  to  overcome  all  problems  of  network  manage¬ 
ment,  is  based  on  CMIP.  The  simplicity  and  the  ease  of  implementation  of  the  SNMP,  re¬ 
sulted  in  its  rapid  design  and  deployment.  These  features  also  solved  the  immediate  prob¬ 
lem  of  managing  the  Internet,  as  well  as  network  management  related  issues  in  other 
networking  environments.  On  the  other  hand,  CMIP  took  longer  to  design,  and  its  im¬ 
plementation  in  enterprise  network  equipment  was  slowed  both  by  its  inherent  complex¬ 
ity  and  the  popularity  of  the  SNMP.  Despite  the  shortcomings  of  both  SNMP  and  CMIP 
technologies,  they  will  likely  be  deployed  in  future  enterprise  network  management  prod¬ 
ucts  [10]. 


F.  SUMMARY 

This  chapter  presented  an  overview  of  how  network  management  functions  are 
implemented  on  a  typical  network.  It  also  discussed  the  management  framework,  the 
management  information  model  and  the  two  main  network  management  protocols.  An 
overview  of  the  DCC,  which  is  a  SONET  in-band  communication  channel  for  the  ex¬ 
change  of  the  management  messages,  is  also  presented. 

The  next  chapter  presents  a  comparison  between  SNMP  and  CMIP,  including  the 
advantages  and  disadvantages  of  each  protocol. 
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III.  SNMP  VERSUS  CMIP 


A.  CHAPTER  OVERVIEW 

This  chapter  presents  a  comparison  between  CMIP  and  SNMP.  Both  the  advan¬ 
tages  and  disadvantages  of  eaeh  protoeol  are  presented.  It  also  discusses  why  SNMP  is 
the  most  popular  network  management  solution  in  use  today. 


B,  INTRODUCTION 

SNMP  and  CMIP  are  the  two  prevalent  network  management  protoeols  in  use  to¬ 
day.  The  use  of  either  network  management  protoeols  depends  on  a  wide  range  of  faetors 
and  both  have  their  advantages  and  disadvantages  (to  be  diseussed  in  detail  later).  It  is 
important  to  understand  that  SNMP  and  CMIP  are  based  on  different  assumptions  [10]; 

1 .  In  SNMP,  the  User  Datagram  Protoeol  (UDP)  is  used  as  the  transport  protoeol 
for  the  exehange  of  the  network  management  messages  between  the  manager 
and  the  agent.  UDP  is  a  eonneetionless  transport  protoeol,  whieh  does  not 
guarantee  the  delivery  of  the  messages.  Henee,  eaeh  request  and  response  be¬ 
tween  the  manager  and  the  agent  is  a  separate  transaetion.  On  the  other  hand, 
in  CMIP,  the  exehange  of  the  requests  and  responses  uses  an  OSI  eonneetion- 
oriented  transport  protocol,  which  provides  sequencing  of  messages  as  well  as 
guaranteed  delivery  [10]. 

2.  In  SNMP,  an  agent  does  not  perform  analysis  on  the  information  it  retrieves  or 
modifies.  Only  the  manager  is  eapable  of  performing  an  analysis  task.  In 
CMIP,  some  manager  functions  are  transferred  to  the  agent,  which  are  eapable 
of  performing  some  analysis  tasks  [10]. 
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C.  SNMP 

1.  Advantages  of  SNMP 

The  main  advantage  of  SNMP  is  its  ease  of  implementation  due  to  its  simple  de¬ 
sign.  The  number  of  messages  required  for  eaeh  request  and  response  is  small  and,  as 
such,  SNMP  does  not  consume  many  system  resources.  In  addition,  due  to  its  simple  de¬ 
sign,  the  variables  that  are  to  be  monitored  can  be  programmed  easily.  The  net  result  of 
SNMP’s  simplicity  is  a  network  manager  that  is  inexpensive,  easy  to  install  and  use  ef¬ 
fectively,  and  has  minimal  impact  on  the  existing  network  [10]. 

Another  advantage  of  SNMP  is  its  widespread  popularity  [13].  It  quickly  became 
the  de  facto  network  management  standard  for  a  wide  range  of  applications.  Almost  all 
major  vendors  of  network  equipment  design  their  products  to  support  SNMP.  Currently, 
there  is  no  development  underway  for  a  network  management  protocol  to  replace  SNMP. 
As  such,  SNMP  will  continue  its  stronghold  as  the  most  popular  network  management 
protocols  [14,15]. 

Expandability  is  another  advantage  of  SNMP.  Due  to  its  simple  design,  it  allows 
enhancements  to  be  added  easily  to  meet  users’  demands.  Various  new  features  have 
been  added  to  SNMP  over  the  past  few  years  and  different  versions  had  been  created.  The 
different  versions  and  enhancements  added  will  be  examined  later  on  in  this  thesis  [14]. 

2,  Disadvantages  of  SNMP 

Like  any  system,  SNMP  has  its  faults;  however,  due  to  its  clever  design  most  of 
these  faults  have  workarounds.  The  major  disadvantage  encountered  by  most  SNMP  is 
weak  security:  network  management  data  is  vulnerable  to  threats  such  as:  modification  of 
management  information  during  transit  between  the  manager  and  agent,  disclosure  of 
management  information  to  unauthorized  users,  and  disruption  of  service  through  equip¬ 
ment  shutdown  [1,14].  Security  features  have  been  added  in  the  latest  release  of  SNMP, 
called  SNMPv3,  in  the  form  of  encryption,  authentication  and  access  control.  These  secu¬ 
rity  features  were  added  to  protect  privacy  of  data  (to  prevent  management  information 
from  being  eavesdropped,  modified,  reordered  and  copied  during  its  transit  between  the 
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manager  and  agent),  prevent  masquerading  and  to  restrict  access  of  management  informa¬ 
tion  to  certain  group  of  users  [1,14]. 

Some  consider  SNMP  unsuitable  for  management  of  large  networks  as  polling  by 
SNMP  managers  affect  network  performance.  In  addition,  critical  messages  concerning 
errors  within  network  devices  sent  by  the  agents  are  not  guaranteed  to  reach  the  NMS. 
This  is  because  the  connectionless  transport  protocol  UDP  is  used  to  exchange  messages 
and,  as  such,  the  traps  sent  will  not  be  acknowledged  [10]. 

Further,  in  every  SNMP  message,  bandwidth  is  wasted  with  unnecessary  informa¬ 
tion,  such  as  SNMP  version  and  multiple  length  and  data  descriptors  (example,  describ¬ 
ing  the  type  of  PDU  sends).  In  addition,  substantial  amount  of  bandwidth  is  being  con¬ 
sumed  by  the  needlessly  large  data  handles:  SNMP  variables  are  defined  as  byte  strings, 
each  corresponding  to  a  particular  managed  object.  Therefore,  SNMP  is  not  a  very  effi¬ 
cient  protocol  [13]. 

The  most  significant  problem  with  SNMP  is  that  it  is  so  simple  that  it  cannot  han¬ 
dle  large  and  expanding  networks  [14].  The  short  design  time  of  SNMP  did  not  allow  suf¬ 
ficient  consideration  of  the  large  amount  of  data  that  would  be  in  exchanged  in  future  ex¬ 
panding  networks.  SNMP  was  not  designed  to  lead  network  management  into  the  21®‘ 
century  [14].  New  enhancements  have  been  included  in  SNMPv2  to  fix  this  problem. 

This  new  version  allows  for  more  in-detail  specification  of  variables,  including  easier  re¬ 
trieval  of  large  blocks  of  data.  This  resulted  in  two  new  protocol  data  units  being  defined 
for  manipulating  the  tabled  objects  [14]. 
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D,  CMIP 

CMIP  was  initially  designed  to  replaee  and  overcome  the  deficiencies  in  SNMP. 

It  is  a  more  robust,  organized  and  detailed  network  manager  than  SNMP.  Hence,  CMIP  is 
more  complex  requiring  a  large  amount  of  system  resources.  In  addition,  CMIP  has  so¬ 
phisticated  data  structures  with  many  attributes.  These  variables  properties  include; 

1 .  Variable  attributes  which  represent  the  variable’s  characteristics,  including  at¬ 
tributes  such  as  whether  it  can  be  readable  or  writable. 

2.  Variable  behaviors  which  indicate  the  type  of  tasks  the  variable  can  perform. 

3.  Notifications  or  asynchronous  reports  generated  by  the  variable  in  the  event  of 
an  unusual  network  conditions,  such  as  an  error  in  a  network  device. 

It  is  noted  that  SNMP’s  variables  possess  only  property  one  and  three  as  stated 
above  [14]. 

1,  Advantages  of  CMIP 

The  major  advantage  of  CMIP  over  SNMP  is  that  its  variables,  besides  capable  of 
relaying  information,  can  be  used  to  perform  tasks.  This  is  impossible  under  SNMP  [14]. 
For  example,  when  CMIP  is  used,  it  can  notify  the  appropriate  personnel  whenever  a  cli¬ 
ent  cannot  reach  a  server  after  pre-determined  number  of  attempts.  However,  with 
SNMP,  a  user  must  explicitly  monitor  the  number  of  unsuccessful  tries  the  client  has 
made  to  reach  the  server.  Hence,  CMIP  is  a  more  efficient  network  management  protocol 
as  compared  to  SNMP,  as  the  above  task  can  be  automated  [14]. 

Another  advantage  of  CMIP  is  that  it  has  inherent  security  features  that  address 
the  security  deficiencies  of  SNMP  [14].  CMIP  has  built-in  security  features  that  support 
authentication,  access  control  and  security  logs.  Hence,  CMIP  is  an  inherently  safer  sys¬ 
tem  than  SNMP  and  does  not  require  for  security  upgrades,  unlike  SNMP  [14]. 
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2,  Disadvantages  of  CMIP 

Based  on  CMIP’s  superior  features,  one  might  question  why  CMIP  has  not  been 
implemented  already;  after  all,  it  has  been  in  development  for  about  ten  years.  The  main 
reason  is  that  the  CMIP  protocol  takes  more  system  resources  than  SNMP  by  a  factor  of 
ten  [14].  In  other  words,  only  large  systems  would  be  able  to  handle  a  full  implementa¬ 
tion  of  CMIP,  resulting  in  very  few  NE  implementations.  The  only  way  to  overcome  this 
disadvantage  is  to  redefine  the  protocol  specifications.  Over  the  past  few  years,  research¬ 
ers  have  developed  several  protocols  to  adapt  CMIP  to  TCP/IP  based  networking  envi¬ 
ronments.  However,  none  of  these  new  enabling  technologies  has  gathered  sufficient 
wide  spread  popularity  to  replace  SNMP  as  the  de  facto  network  management  standard 
[14]. 

Another  disadvantage  of  CMIP  is  that  it  is  very  complex,  hence  very  difficult  to 
program  its  variables.  Programmers  need  to  undergo  specialized  training  to  be  able  to  de¬ 
velop  and  maintain  applications  and  operate  CMIP-based  NMS  [14]. 


E.  CONCLUSION 

The  above  discussion  has  presented  the  advantages  and  disadvantages  of  SNMP 
and  CMIP.  Based  on  the  above  comparison  between  them,  the  choice  between  these  net¬ 
work  management  systems  depends  largely  on  its  implementation.  Even  though,  CMIP  it 
is  superior  to  SNMP  (vl,  and  v2)  in  design  and  operation,  current  available  systems  are 
realistically  unable  to  support  CMIP-based  NMS  due  to  its  requirement  for  large  system 
resources  to  support  the  CMIP  model  [14]. 

Initially,  SNMP  was  designed  to  be  a  temporary  solution  and  stop-gap  measure 
for  network  management  until  a  better  method  could  be  developed.  However,  SNMP 
continued  to  evolve  and  is  currently  supported  by  almost  every  enterprise  network 
equipment  manufacturer  worldwide  [1,4].  Due  to  SNMP’s  simple  design,  modular  nature 
and  the  addition  of  security  features  in  SNMPvS,  it  has  continued  to  be  the  de  facto  net¬ 
work  management  standard.  [1]. 

In  the  next  chapter,  a  brief  overview  of  the  key  concepts  of  SNMP  which  includes 
the  key  components  of  SNMP,  the  information  model  used  in  SNMP,  and  SNMP  data 
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representation  is  presented.  In  addition,  the  SNMP  operations,  message  format  and  de- 
seriptions  of  the  SNMPvl,  SNMPv2  and  SNMPvS  protocol  operations  are  covered. 
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IV.  SIMPLE  NETWORK  MANAGEMENT  PROTOCOL 


A.  CHAPTER  OVERVIEW 

This  chapter  provides  a  brief  overview  of  the  key  eoneepts  of  SNMP.  This  in- 
eludes  the  key  eomponents  of  SNMP,  the  information  model  used  in  SNMP,  and  SNMP 
data  representation.  In  addition,  it  also  eovers  the  SNMP  operations  and  message  format 
and  provides  deseriptions  of  the  SNMPvl,  SNMPv2  and  SNMPvS  protoeol  operations. 


B,  INTRODUCTION 

SNMP  is  an  applieation  layer  protoeol  based  on  the  Transmission  Control  Proto¬ 
col/Internet  Protoeol  (TCP/IP)  protoeol  suite  whieh  offers  network  management  serviees 
for  monitoring  and  eontrol  of  network  deviees.  SNMP  enables  network  administrators  to 
manage  network  performanee,  find  and  solve  network  problems,  and  plan  for  network 
growth.  SNMP  is  a  network  management  tool  that  allows  network  administrator  to  per¬ 
form  monitoring,  eontrol  and  planning  tasks  on  the  network  to  be  managed  [16]. 

There  are  currently  three  versions  of  SNMP:  SNMPvl,  SNMPv2  and  SNMPvS. 
The  modular  design  of  SNMP  is  shown  in  the  consistency  of  the  architecture,  structure, 
and  framework  of  all  three  versions;  this  aides  gradual  evolution  of  protoeol  enhanee- 
ments.  Though  SNMPvl  was  effective  and  easy  to  implement,  it  had  its  problems  and 
limitations.  Enhaneements  to  SNMPvl,  resulted  in  a  new  SNMP  version,  SNMPv2, 
whieh  also  eorreeted  the  bugs  and  limitations  in  SNMPvl.  However,  these  new  en¬ 
haneements  did  not  address  seeurity  defieieneies,  sueh  as  privaey  of  data,  masquerading 
and  unauthorized  diselosure  of  data.  Subsequently,  SNMPvS  was  then  developed  to  ad¬ 
dress  these  seeurity  defieieneies:  SNMPvS  added  seeurity  features,  sueh  as  aeeess  eon¬ 
trol,  authentication,  and  encryption  of  management  data  [1]  (see  Figure  2,  [15]).  The 
SNMPvS  specifieations  were  approved  by  the  Internet  Engineering  Steering  Group 
(lESG)  as  full  Internet  Standard  in  Mareh  2002,  and  vendors  have  begun  to  support 
SNMPvS  in  their  products. 
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Manacjer  Transmission  from  manager 
to  agent  may  be  authenticated 
to  guarantee  identity  of  sender 
and  integrity  and  timeliness 
of  message 


Agent 


Agent 


SNMPv3  messages 
may  be  encrypted 
to  ensure  privacy 


Manager 


Agent  may  enforce  access- control 
policy  to  restrict  each  principal  to 
certain  actions  on  certain  portions 
of  its  data 


Agent 


Figure  2  Highlights  of  SNMPvS  Security  Features  (From  Ref  [15].) 


C.  SNMP  BASIC  COMPONENTS 

The  three  key  components  of  a  SNMP -based  network  device  are  managed  de¬ 
vices,  agents,  and  network  management  systems  (NMSs). 

A  managed  device,  also  known  as  a  network  element  (NE),  has  a  built-in  SNMP 
agent  and  resides  on  a  managed  network.  The  managed  device  collects  and  stores  man¬ 
agement  information,  such  as  network  statistics  and  traffic  information,  so  that  this  in¬ 
formation  can  be  made  available  to  NMSs  whenever  it  is  requested.  Optical  line  terminals 
(OLTs),  optical  add/drop  multiplexers  (OADMs),  optical  amplifiers,  and  optical  cross¬ 
connects  (OXCs)  are  some  examples  managed  devices  in  optical  networks.  An  agent,  re¬ 
siding  in  a  managed  device,  is  a  software -based  network-management  module  that  trans¬ 
lates  available  local  knowledge  of  management  information  into  a  format  compatible 
with  SNMP  [16]. 
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A  NMS  is  like  the  “brain”  of  network  management,  it  executes  network  manage¬ 
ment  applications  that  initiate  requests  to  read  and  write  to  the  NEs;  the  NMS  also  pro¬ 
vides  most  of  the  processing  capability  as  well  as  memory  resources.  In  order  to  effec¬ 
tively  manage  a  network,  one  or  more  NMSs  must  coexist  together  to  manage  the  entire 
network.  The  relationships  of  these  three  components  are  shown  in  Figure  3  [16]. 


Managem^fll 


Managed  devices 


Figure  3  A  SNMP-Managed  Network  Consists  of  Managed  Devices,  Agents,  and 

NMSs  (From  Ref.  [16].) 

D,  SNMP  MANAGEMENT  INFORMATION  BASE 

The  information  model  in  SNMP  is  called  Management  Information  Base  (MIB). 
A  MIB  is  a  collection  of  all  objects  which  can  be  managed  by  SNMP.  Each  object  is 
identified  by  a  unique  object  identifier  (or  object  ID).  A  MIB  is  organized  in  a  hierarchi¬ 
cal  or  tree  structure  and  is  accessible  using  a  network-management  protocol  such  as 
SNMP. 

A  managed  object  (sometimes  called  a  MIB  object,  an  object,  or  a  MIB)  repre¬ 
sents  a  specific  characteristic,  activity  or  related  information  of  a  managed  device.  There 
are  two  types  of  managed  objects,  scalar  and  tabular.  Managed  objects  with  a  single  ob- 
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ject  instance,  i.e.,  variable,  are  ealled  sealar  objeets;  managed  objeets  with  multiple  re¬ 
lated  objeet  instances,  grouped  in  MIB  tables,  are  ealled  tabular  objeets. 

An  objeet  identifier  is  a  unique  identifier  for  a  particular  object  type  in  the  MIB 
tree  strueture.  All  logieally  related  objects  are  grouped  together  in  the  tree  strueture  with 
a  nameless  root.  Figure  4  illustrates  the  MIB  tree.  Objeet  identifiers  at  eaeh  level  of  the 
MIB  tree  structure  are  assigned  by  different  organizations;  the  different  standards  organi¬ 
zations  eontrol  the  top-level  MIB  objeet  identifiers,  while  their  assoeiated  organizations 
alloeate  identifiers  at  the  lower-levels.  The  managed  objects  in  the  private  braneh,  as 
shown  in  Figure  4,  are  defined  by  vendors  for  their  own  products.  The  experimental 
braneh  is  typieally  used  to  identify  those  non-standardized  MIBs  [16]. 

A  managed  objeet  can  be  identified  either  by  the  objeet  name  or  object  descriptor. 
For  example,  the  managed  objeet  atinput  ean  be  uniquely  identified  either  by  the  object 
name — iso. identified-organization.dod.internet.private. enterprise. eiseo. temporary  vari¬ 
ables.  AppleTalk.atInput — or  by  the  equivalent  objeet  deseriptor,  1.3. 6. 1.4. 1.9. 3. 3.1  (see 
Figure  4)  [16]. 
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Figure  4  The  MIB  Tree  Illustrates  the  Various  Flierarchies  Assigned  by  Different 

Organizations  (From  Ref.  [16].) 

E.  SNMP  AND  DATA  REPRESENTATION 

SNMP  is  responsible  for  translating  different  data  representation  techniques  that 
are  used  by  different  networking  computing  devices  into  a  common  data  representation 
language.  The  difference  in  data-type  definition  language  between  managed  devices  can 
compromise  the  capability  of  SNMP  to  exchange  information  between  managed  devices. 
SNMP  overcomes  these  incompatibilities  between  diverse  systems  by  using  a  subset  of 
Abstract  Syntax  Notation  One  (ASN.l).  ASN.l  provides  a  standardized  way  to  represent 
data  to  allow  for  interoperability  [16]. 
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F.  PARTIES 

SNMPv3  introduces  the  eoneept  of  a  “party”,  whieh  is  a  logieal  SNMPv3  entity 
that  ean  request  or  receive  SNMPv3  eommunieation  between  two  parties.  Eaeh  SNMPv3 
party  is  defined  as  a  single,  unique  party  identity,  a  logieal  network  loeation,  a  single  au- 
thentieation  protoeol,  and  a  single  privacy  protocol.  However,  a  SNMPv3  entity  ean  also 
be  defined  as  multiple  parties,  but  with  different  parameters,  i.e.,  having  different  authen- 
tieation  and/or  privaey  protoeols  [17]. 


G.  SNMP  OPERATIONS 

1,  SNMPvl  Protocol  Operations 

SNMP  is  a  simple  request/response  protoeol  that  eommunieates  management  in¬ 
formation  between  the  NMS  and  managed  deviees.  Typieally,  when  a  NMS  initiates  a  re¬ 
quest  to  retrieve  or  modify  management  information,  such  as  a  network  statistie,  the  man¬ 
aged  device  will  return  a  response.  There  are  four  different  protoeol  operations  that  allow 
the  implementation  of  the  above  behavior:  “Get”,  “GetNext”,  “Set”,  and  “Trap”.  The 
NMS  uses  the  Get  operation  to  retrieve  the  value  of  one  or  more  objeet  instanees  from  an 
agent.  The  agent  will  not  provide  any  values  in  its  response  if  any  of  the  objeet  instanees 
in  a  list  is  not  suoeessfully  found  and  retrieved.  Rather,  if  the  retrieval  is  unsueeessful,  the 
appropriate  error  is  sent  in  the  response.  If  the  NMS  does  not  know  the  next  objeet  in- 
stanee  from  a  known  managed  objeet  instanee,  it  will  use  the  GetNext  operation  to  re¬ 
trieve  the  value  of  the  next  object  instance  in  a  table  or  a  list  within  an  agent.  In  order  to 
modify  the  values  of  object  instances  within  an  agent,  the  NMS  uses  the  Set  operation. 
When  a  signifieant  event  oeeurs,  the  agents  use  the  Trap  operation  to  send  an  unsolieited 
notifieation  to  the  NMS  [16].  Figure  5  shows  the  arehitecture  of  SNMPvl,  whieh  details 
the  various  protoeol  operations  between  a  NMS  and  a  managed  deviee  [4]. 
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Figure  5  SNMPvl  Architecture  (From  Ref.  [4].) 

2,  SNMPv2  Protocol  Operations 

In  SNMPv2,  the  Get,  GetNext,  and  Set  operations  are  exactly  the  same  as  in 
SNMPvl.  However,  SNMPv2  adds  two  new  protocol  operations  and  enhances  the  Trap 
operations.  The  only  difference  between  the  SNMPv2  Trap  operation  and  that  used  in 
SNMPvl  is  the  message  format;  otherwise,  both  serve  same  function. 

The  two  new  protocols  operations  as  defined  in  SNMPv2  are  GetBulk  and  In¬ 
form.  The  GetBulk  operation  provides  efficient  bulk  retrieval  for  large  blocks  of  data  in 
multiple  rows  of  a  table,  allowing  the  NMS  to  retrieve  as  much  data  as  possible  in  a  sin¬ 
gle  operation.  The  amount  of  data  being  retrieved  is  dependent  on  the  size  of  a  response 
message.  In  SNMPv2,  the  agent  responding  to  GetBulk  operations  will  provide  partial  re¬ 
trieval  even  if  some  of  the  variables  in  a  list  are  not  successfully  found  and  retrieved.  The 
other  new  protocol  operation  is  the  Inform  operation;  it  allows  trap  information  to  be 
communicated  between  two  NMSs  [16]. 
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3,  SNMPv3  Protocol  Operations 

Due  to  the  modular  nature  of  SNMP,  SNMPv3  is  designed  to  be  baekward  eom- 
patible  with  SNMP  versions  1  and  2.  SNMPv3  is  essentially,  SNMPv2  with  the  addition 
of  three  important  security  features:  access  control,  authentication,  and  encryption,  along 
with  other  enhancements.  Thus,  SNMPv3  is  based  upon  the  protocol  operations  and  data 
types  from  SNMPv2. 

Two  key  significant  additions  provided  by  SNMPv3  are  the  User-based  Security 
Model  (USM)  and  View-based  Access  Control  Model  (VACM).  The  USM  of  SNMPv3 
defines  mechanisms  for  providing  authentication  and  privacy  for  message-level  security 
in  SNMP  implementations.  The  VACM  of  SNMPv3  defines  mechanisms  for  providing 
access  control  facility  for  providing  different  levels  of  access  control  (read,  write,  notify) 
to  each  piece  of  management  information  for  different  users  [1]. 


H.  SNMPVl  MESSAGE  FORMATS 

The  SNMPvl  messages,  defined  in  ASN.l  format,  are  organized  into  two  main 
parts,  a  message  header  and  a  protocol  data  unit  (PDU).  Figure  6  illustrates  the  basic 
format  of  a  SNMPvl  message.  The  message  header  contains  a  version  and  a  community 
name.  The  PDU  contains  the  actual  SNMP  PDU.  It  specifies  one  of  the  SNMPvl  proto¬ 
col  operations  ("Get,"  "Set,"  and  etc.)  and  the  object  instances  involved  in  the  operation 
[16,17]. 


Message  Header 


PDU 


Figure  6  SNMPvl  Message  Format  (From  Ref.  [16].) 
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1,  SNMPvl  Message  Header 

There  are  two  fields  in  the  SNMPvl  message  header,  Version  Number  and  Com¬ 
munity  Name.  The  version  field  is  used  for  SNMP  eompatibility.  This  is  to  ensure  that 
the  software  used  by  all  NEs  is  of  the  same  SNMP  version.  The  eommunity  name  is  used 
as  a  weak  form  of  authentieation  because  devices  that  do  not  know  the  valid  community 
strings  will  ignore  the  SNMP  request.  Therefore,  a  predefined  set  of  NMSs  having  the 
same  community  name  are  said  to  exist  within  the  same  administrative  domain  [17]. 

2,  SNMP  Protocol  Data  Unit 

SNMPvl  PDUs  contain  information  such  as  the  type  of  SNMPvl  protocols  opera¬ 
tions  (“Get”,  “Set”,  and  etc.),  message  sequencing,  error  status  and  condition,  and  object 
instances  involved  in  the  operation.  The  length  of  SNMPvl  PDU  field  is  dependent  on 
the  list  of  object  instances  specified;  hence  its  length  is  variable.  Figure  7  illustrates  the 
fields  of  the  SNMPvl  Get,  GetNext,  Response,  and  Set  PDUs  transactions  and  Table  2 
below  provides  a  summary  of  the  descriptions  of  the  fields  [16]. 


PDU 

Type 

Request 

ID 

Error 

Status 

Error 

Index 

Object  1 
Value  1 

Object  2 
Value  2 

1  Object  X 

1  Value  X 

1 

1 

Variable  bindings 


Figure  7  SNMPvl  Get,  GetNext,  Response,  and  Set  PDUs  Contain  the  Same  Fields 

(From  Ref.  [16].) 
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Field 

Deseription 

PDU  type 

Speeifies  the  type  of  PDU  transmitted. 

Request  ID 

Assoeiates  SNMP  requests  with  responses. 

Error  status 

Indieates  one  of  a  number  of  errors  and  error  types.  Only  the  response 

operation  sets  this  field.  Other  operations  set  this  field  to  zero.  In 

SNMPv2  and  SNMPv3  GetBulk  operations,  this  field  beeomes  a  Non- 

Repeaters  field. 

Error  index 

Assoeiates  an  error  with  a  particular  object  instance.  Only  the  response 

operation  sets  this  field.  Other  operations  set  this  field  to  zero.  In 

SNMPv2  and  SNMPv3  GetBulk  operations,  this  field  becomes  a  Max 

Repetitions  field. 

Variable 

bindings 

Serves  as  the  data  field  of  the  SNMP  PDU.  Each  variable  binding  associ¬ 
ates  a  particular  object  instance  with  its  current  value. 

Table  2  Summary  of  SNMPvl  Get,  GetNext,  Response,  and  Set  PDUs  fields  de- 

seription  (After  Ref.  [16].) 


3.  Trap  PDU  Format 

Figure  8  illustrates  the  fields  of  the  SNMPvl  Trap  PDU  and  Table  3  below  pro¬ 


vides  a  summary  of  the  deseriptions  of  the  fields. 
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Variable  bindings 


Figure  8  SNMPvl  Trap  PDU  (After  Ref.  [16].) 
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Field 

Deseription 

Enterprise 

Identifies  the  type  of  managed  objeet  generating  the  trap. 

Agent  address 

Provides  the  address  of  the  managed  objeet  generating  the  trap 

Generie  trap  type 

Indieates  one  of  a  number  of  generie  trap  types. 

Speeifie  trap  eode 

Indieates  one  of  a  number  of  speeifie  trap  eodes. 

Time  stamp 

Provides  the  amount  of  time  that  has  elapsed  between  the  last  net¬ 
work  reinitialization  and  generation  of  the  trap. 

Variable  bindings 

The  data  field  of  the  SNMPvl  Trap  PDU.  Eaeh  variable  binding 

assoeiates  a  partieular  objeet  instanee  with  its  eurrent  value. 

Table  3  Summary  of  SNMPvl  Trap  PDU  fields  deseription  (After  Ref.  [16].) 


I,  SNMPV2  MESSAGE  FORMAT 

SNMPv2  messages,  defined  in  ASN.l  format,  are  virtually  identieal  to  that  of 
SNMPvl  messages  (see  the  previous  deseription  of  an  SNMP  PDU  for  differenees).  De¬ 
pending  on  the  SNMP  protoeol  operation,  the  SNMPv2  PDU  formats  may  differ. 
SNMPv2  PDU  fields  are  also  variable  in  length  [16,17]. 

Figure  9  illustrates  the  fields  of  the  SNMPv2  Get,  GetNext,  Inform,  Response, 
Set,  and  Trap  PDUs.  The  fields  deseriptions  illustrated  in  Figure  9  are  identieal  to  that  of 
a  SNMPvl  Get,  GetNext,  Response,  and  Set  PDUs. 
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Figure  9  SNMPv2  Get,  GetNext,  Inform,  Response,  Set,  and  Trap  PDUs  Contain 

the  Same  Fields  (From  Ref  [16].) 
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Figure  10  illustrates  the  fields  of  the  SNMPv2  GetBulk  PDU.  Within  this  PDU, 
the  fields  Non  repeaters  and  Max  repetitions  replace  the  Error  status  and  Error  index 
fields  shown  in  Eigure  7.  The  GetBulk  operation  uses  the  Non  repeaters  and  Max  repeti¬ 
tions  fields  to  specify  how  much  information  is  retrieved.  Non  repeaters  specify  the  num¬ 
ber  of  object  instances  in  the  variable  bindings  field  that  should  be  retrieved  once  (typi¬ 
cally  for  scalar  objects  with  only  one  variable)  from  the  beginning  of  the  request.  Max 
repetitions  define  the  maximum  number  of  times  that  other  variables,  other  than  those 
specified  by  the  Non  repeaters  field  should  be  retrieved  [16]. 
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Eigure  10  SNMPv2  GetBulk  PDU  (After  Ref.  [16].) 

J.  SNMPV3  MESSAGE  FORMAT 

Eike  SNMPv2  messages,  SNMPv3  messages  (shown  in  Figure  1 1)  contain  two 
parts.  The  second  part  of  the  SNMPv3  message  (the  PDU)  is  identical  to  that  of  a 
SNMPv2  message.  The  main  difference  between  SNMPv2  and  SNMPv3  is  on  the  first 
part  of  the  SNMPv3  message. 


Wrapper 


PDU 


Figure  1 1  SNMPv3  Message  Format  (From  Ref  [17].) 


The  wrapper  forms  the  first  part  of  a  SNMPv3  message.  It  contains  authentication 
and  privacy  information  that  are  defined  in  the  destination  and  source  parties  (see  Section 
F  for  more  detailed  explanation  about  a  party).  In  addition  to  a  destination  and  a  source 
party,  a  context,  which  specifies  the  managed  objects  involve  in  an  operation,  is  defined 
in  the  wrapper  [17]. 
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The  authentication  protocol  is  designed  to  ensure  that  a  received  message  was,  in 
fact,  transmitted  by  the  originating  SNMPv3  party.  It  consists  of  authentication  informa¬ 
tion  required  to  support  the  authentication  protocol  used.  The  privacy  protocol  is  de¬ 
signed  to  prevent  eavesdropping  by  unauthorized  users.  In  order  for  the  message  to  be 
protected  from  disclosure,  the  message  must  also  be  authenticated  [17]. 

There  are  two  primary  security  protocols  that  are  defined  in  the  SNMPv3  specifi¬ 
cations,  the  Digest  Authentication  Protocol,  designed  for  authentication  purposes,  and  the 
Symmetric  Privacy  Protocol,  designed  to  ensure  message  privacy  [17]. 

The  Digest  Authentication  Protocol  verifies  that  the  message  received  is,  in  fact, 
from  the  original  sender.  This  is  to  ensure  data  integrity  and  prevents  masquerading.  A 
128-bit  message  digest  is  calculated  using  the  Message  Digest  5  (MD5)  algorithm  at  the 
sender  to  protect  data  integrity.  The  algorithm  produces  an  authentication  value  and  en¬ 
closes  it  within  the  SNMPv3  message.  The  receiver  applies  the  same  MD5  algorithm  and 
verifies  the  digest.  After  the  message  integrity  is  verified,  a  secret  key  known  only  to  the 
sender  and  the  receiver  and  prefixed  to  the  message  is  used  to  verify  the  message’s  origin 
[17]. 

The  Symmetric  Privacy  Protocol  is  used  to  ensure  message  privacy  by  encrypting 
the  message  with  Data  Encryption  Standard  (DES)  algorithm.  When  this  encrypted  mes¬ 
sage  is  sent  or  received,  both  the  sender  and  receiver  of  the  message  must  have  the  same 
secret  encryption  key,  known  only  to  both  of  them.  [17].  This  is  to  prevent  eavesdropping 
and  ensure  privacy  of  management  information. 


K.  SUMMARY 

This  chapter  provided  a  brief  overview  of  the  key  concepts  of  SNMP.  This  in¬ 
cluded  the  key  components  of  SNMP,  the  information  model  used  in  SNMP,  and  SNMP 
data  representation.  It  also  presented  the  evolution  and  features  of  the  three  different  ver¬ 
sions  of  SNMP.  In  addition,  it  also  covered  the  SNMP  protocol  operations  in  each  SNMP 
versions,  as  well  as  each  message  format. 

In  the  next  chapter,  traffic  analysis  is  performed  on  real,  operational  SNMP  traffic 
and  statistics  are  developed  from  the  SNMP  traffic. 
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V.  TRAFFIC  ANALYSIS  OF  SNMP  TRAFFIC 


A.  CHAPTER  OVERVIEW 

This  chapter  presents  traffie  analysis  performed  on  SNMP  traffie  colleeted  by  the 
Naval  Postgraduate  Sehool  (NPS)  Network  Operations  Center  (NOC).  This  analysis  was 
neeessary  in  understanding  the  traffie  parameters,  sueh  as  polling  interval,  request  inter¬ 
arrival  time,  request  paeket  size,  ete.,  of  aetual  SNMP  traffie.  From  this  traffie  analysis, 
statisties  for  the  paeket  size  and  inter-arrival  time  of  the  Get  request  and  the  Get  response 
messages  with  respeet  to  a  NMS  and  an  agent  are  developed. 


B.  INTRODUCTION 

The  objeetive  of  this  traffie  analysis  is  to  determine  the  paeket  size  of  eaeh  re¬ 
quest/response,  number  of  paekets  per  request/response,  request/response  inter-arrival 
times  and  polling  interval.  With  the  understanding  of  the  SNMP  traffic,  statistics  were 
developed  and  these  statisties  were  used  to  speeify  a  SNMPvl  definition  in  OPNET.  Sub¬ 
sequently,  the  SNMPvl  definition  was  integrated  into  an  OPNET  network  model  to  study 
the  sealability  issues  of  SNMP-based  polling  in  an  optieal  network. 


C.  TRAFFIC  MEASUREMENTS 

The  measurement  of  the  SNMP  traffie  was  eolleeted  from  NPS  eampus  network 
via  the  NOC.  The  measured  SNMP  traffie  was  the  management  data  that  is  used  to  moni¬ 
tor  the  network  status  of  infrastrueture  deviees  throughput  the  NPS  eampus.  In  this  traffie 
analysis,  the  SNMP  traffie  was  eaptured  using  Etherpeek  (paeket  sniffer).  Erom  the 
SNMP  message  header,  the  SNMP  version  eould  be  determined  and  it  was  found  that  the 
measured  SNMP  traffie  was  SNMPvl.  Based  on  the  measured  SNMP  traffie,  it  was 
found  that  the  SNMP  polling  interval  for  the  eolleetion  of  the  management  data  statisties 
was  approximately  five  seconds.  The  SNMP  protoeol  operations  in  the  measured  SNMP 
traffie  eonsist  of  SNMPvl  Get  and  Trap  messages.  As  observed  from  the  measured 
SNMP  traffie,  SNMP-defined  traps  are  signifieantly  less  frequent  eompared  to  the  SNMP 
Get  request-responses.  Eurthermore,  proprietary  traps  frequently  are  not  understood  by 
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network  management  stations  from  other  vendors.  Thus,  virtually  all  required  informa¬ 
tion  that  is  needed  by  the  management  station  is  gathered  by  polling  (Get  Request).  In 
this  study,  we  only  looked  at  the  Get  messages.  Figure  12  shows  the  screen  shot  of  an 
Etherpeek  capture  of  a  typical  SNMP  Get  request  packet  behavior  between  NMS  and 
agent.  Initially,  fifteen  thousand  packets  of  traffic  were  captured.  However,  in  this  study, 
we  were  only  interested  in  the  SNMP  traffic  originating  from  the  NMS,  i.e..  Get  request, 
and  the  SNMP  traffic  originating  from  a  frequently  polled  agent,  i.e..  Get  response. 
Therefore,  after  filtering  those  traffic  sources  irrelevant  to  our  study,  approximately  eight 
thousand  packets  were  left.  This  traffic  sample  size  was  still  considered  large  enough  to 
perform  a  rough  but  meaningful  statistical  traffic  analysis.  These  results  were  later  com¬ 
pared  with  a  four-hour  study  and  found  to  be  consistent.  There  were  a  total  of  29  different 
agents,  i.e.,  the  NMS  was  monitoring  29  different  NEs.  However,  in  this  study,  we  only 
performed  analysis  on  the  SNMP  traffic  between  the  NMS  and  the  frequently  polled 
agent. 
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Eigure  12  Screen  shot  of  an  Etherpeek  capture  showing  a  typical  SNMP  Get  request 

packet  between  NMS  and  agent. 


D.  TRAFFIC  ANALYSES  AND  RESULTS 

Analyses  were  performed  separately  on  the  filtered  SNMP  traffic:  one  for  the  Get 
request  from  the  NMS  to  the  agent  and  the  other  for  the  Get  response  from  agent  to  NMS. 
Various  statistics,  including  maximum,  minimum,  mean  and  variance  of  packet  sizes,  and 
request  and  response  inter- arrival  times,  were  collected.  Table  4  shows  the  statistics  asso¬ 
ciated  with  the  filtered  SNMP  traffic. 
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1.  Packet  Sizes  of  SNMP  Traffic 

From  the  filtered  SNMP  traffic  data,  the  statistics  of  the  packet  sizes  of  Get  re¬ 
quest  and  Get  response  with  respect  to  the  NMS  and  the  agent  were  computed  (see  Table 
4).  Based  on  the  measured  SNMP  traffic,  it  was  observed  that  one  packet  is  sent  for  every 
Get  request  or  Get  response  message.  Each  Get  request  packet  size  was  almost  the  same, 
approximately  88  bytes.  However,  based  on  the  measured  SNMP  traffic,  it  was  observed 
that  each  Get  response  packet  size  varied  and  was  dependent  on  the  type  of  NE  that  the 
NMS  was  managing  as  well  as  the  MIB  that  was  being  requested  by  the  NMS.  As  a  re¬ 
sult,  there  was  a  large  variance  in  the  Get  response  packet  sizes  as  compared  to  the  Get 
request  packet  sizes.  Hence,  based  on  the  measured  SNMP  traffic,  the  average  Get  re¬ 
quest  and  Get  response  packet  size  was  approximately  88  bytes  and  93  bytes  respectively. 


Average 

(bytes) 

Variance 

(bytes) 

Minimum 

(bytes) 

Maximum 

(bytes) 

Get  request 

88.73 

0.4186 

86 

89 

Get  response 

93.48 

37.74 

86 

206 

Table  4  Statistics  of  Get  request  and  Get  response  packet  sizes  from  filtered 

SNMP  traffic  data 

2.  Inter-arrival  Times  of  SNMP  Traffic 

Prom  the  filtered  SNMP  traffic  data,  the  statistics  of  the  Get  request  and  Get  re¬ 
sponse  inter- arrival  times  with  respect  to  the  NMS  and  the  agent  were  computed  (see  Ta¬ 
ble  5).  To  obtain  more  accurate  statistics  of  the  actual  Get  request  inter-arrival  times, 
analysis  was  also  performed  on  the  inter-arrival  times  from  the  original  measured  SNMP 
traffic,  i.e.  unfiltered,  and  the  statistics  were  also  computed  (Table  5).  Besides  polling  the 
most  frequently  polled  agent,  the  NMS  also  polled  the  other  agents.  Consequently,  the 
average  Get  request  inter-arrival  time  obtained  from  the  filtered  SNMP  traffic  represents 
the  time  in  between  polls  of  a  specific  agent.  As  might  be  expected,  this  was  higher  than 
the  Get  request  inter- arrival  time  obtained  from  the  original  measured  SNMP  traffic. 
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Hence,  the  average  Get  request  inter-arrival  times  were  56  ms  and  276  ms  as  obtained 
from  the  original  measured  SNMP  traffic  and  the  filtered  SNMP  traffic  respectively. 

The  average  Get  response  inter-arrival  time  was  210  ps.  This  represents  the  time 
it  took  an  agent  to  respond  to  a  Get  request. 


Average 

(s) 

Variance 

(s) 

Minimum 

(s) 

Maximum 

(s) 

Get  request  (fdtered) 

0.276 

2.64 

0.733x10^' 

26.0007 

Get  request  (unfdtered) 

0.056 

0.1024 

0.468x10  ' 

4.62 

Get  response  (fdtered) 

0.21x10^^ 

10.34x10*' 

0.077x10  ' 

2.25x10  ' 

Table  5  Statistics  of  Get  request/response  inter- arrival  times 


E.  CONCLUSIONS 

Based  on  the  above  traffic  analysis,  the  measured  SNMP  traffic  has  an  average 
Get  request  packet  size  of  88  and  Get  response  packet  size  of  93.  The  average  Get  request 
inter- arrival  time  was  56  ms  from  the  original  measured  SNMP  traffic  and  average  Get 
response  inter-arrival  time  was  210  ps,  with  a  polling  interval  of  5  s.  We  used  these  sta¬ 
tistics  to  model  the  SNMP  traffic  in  OPNET  and  subsequently  evaluated  how  well  SNMP 
scales  in  an  optical  network. 

In  the  next  chapter,  the  modeling  of  SNMP,  including  the  simulation  module, 
simulation  parameters  and  test  scenarios  used  in  the  study  are  discussed.  The  simulation 
results  obtained  with  respect  to  the  scalability  of  SNMP  in  a  typical  optical  network  is 
also  discussed. 
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VI  MODELING  OF  SNMP  USING  OPNET 


A.  CHAPTER  OVERVIEW 

This  chapter  describes  the  modeling  of  SNMP,  ineluding  the  simulation  module, 
simulation  parameters  and  test  scenarios  used  in  the  study.  The  test  seenarios  explored 
the  effeet  of  varying  the  number  of  nodes  and  the  request  inter-arrival  times  and  deter¬ 
mine  the  optimum  number  of  nodes  to  be  managed  for  a  speeified  polling  interval.  It  also 
discusses  the  simulation  results  obtained  with  respect  to  the  scalability  of  SNMP  in  a 
typical  optical  network. 

B.  SIMULATION  MODULE 

In  this  study,  OPNET  IT  Guru  1 0.0  [18]  was  used  as  a  modeling  and  simulation 
tool  to  analyze  the  performance  of  SNMP  behavior  in  an  optical  network.  OPNET  is  a 
modeling  and  simulation  tool  that  provides  an  environment  for  analysis  of  communica¬ 
tion  networks.  However,  OPNET  does  not  have  a  SNMP  model  in  its  standard  model  li¬ 
brary.  Therefore,  in  order  to  represent  and  study  the  behavior  of  SNMP  traffic  in  the  net¬ 
work  management  system,  a  simulation  module  ealled  SNMP  Module  was  developed. 
The  most  eommonly  used  version  of  SNMP  is  version  1  (SNMPvl);  therefore,  in  this 
study  SNMPvl  was  modeled  in  OPNET.  With  information  regarding  SNMP  fundamen¬ 
tals  and  coneepts,  as  well  as  the  statisties  obtained  from  the  traffic  analysis,  the  SNMPvl 
model  can  be  defined  and  developed  using  the  custom  application  model.  Hence,  a  repre¬ 
sentation  of  the  expeeted  behavior  of  the  SNMPvl  NMS-agent  relationship  was  ereated 
in  OPNET  and  integrated  into  an  OPNET  network  model  to  study  scalability  issues  of 
SNMP-based  polling. 

C.  SIMULATION  PARAMETERS 

The  network  eonfiguration  for  this  study  eonsists  of  a  NMS,  a  router  and  a  node, 
where  the  agent  resides  (Eigure  13).  The  data  rate  of  the  duplex  link  eonneeting  these 
NEs  is  768  kbps  (simulating  the  data  rate  of  DCC  in  the  SONET  frame,  see  Chapter  II, 
Seetion  C).  As  explained  in  Chapter  II  Seetion  C,  the  DCC  earries  only  the  management 
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data  traffic.  As  such  the  communication  between  NMS  and  the  agent  is  for  network  man¬ 
agement  purpose  only  (i.e.,  SNMP  traffic  only). 
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Figure  13  The  SNMP  Module  as  modeled  in  OPNET 
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The  SNMP  traffic  characteristics  can  be  modeled  by  defining  the  following  at¬ 
tributes  (Table  6)  into  the  Application,  Profile  and  Task  configuration  of  the  OPNET  cus¬ 
tom  application. 


Attribute 

Value 

Object 

Tank  rate 

768  kbps 

Tank 

Transport  Protocol 

UDP 

App  Config 

Request  packet  size  (bytes) 

scripted 

Task  Config 

Request  inter-arrival  time 

varies 

Profile  Config 

Number  of  nodes 

varies 

Profile  Config 

Table  6  Attributes  set  in  the  SNMP  application 


SNMPvl  was  modeled  as  a  custom  application  in  OPNET  and  was  defined  in  the 
‘App  Config’  object  in  OPNET,  whereby  the  transport  protocol  is  also  defined,  i.e., 

UDP.  The  modeling  of  the  custom  application  is  broken  down  into  task  and  phase  under 
the  ‘Task  Config’  object  in  OPNET.  The  task  will  be  the  SNMPvl  Get  operation  and  the 
phase  will  be  the  Get  request  that  is  sent  from  the  NMS  to  the  agent.  The  Get  request  traf¬ 
fic  parameters  are  set  in  the  traffic  attribute  under  the  phase  in  the  ‘Task  Config’  object 
(see  Eigure  14).  As  discussed  earlier  in  Chapter  V  (traffic  analysis),  there  is  only  one 
packet  sent  per  Get  request.  Since  the  pre-defined  distributions  in  OPNET  for  the  request 
packet  size  in  bytes  do  not  fit  into  our  modeling  requirements,  a  “scripted  file”  was  cre¬ 
ated.  The  “scripted  file”  was  generated  by  entering  all  request  packet  sizes,  as  obtained 
from  the  measured  SNMP  traffic,  on  each  line  (representing  an  outcome  for  a  particular 
attribute)  of  the  text  editor.  Once  this  file  is  created,  it  must  be  saved  under  the  “.csv”  or 
“.gdf  ’  extension  so  that  the  data  can  be  read  and  replayed  line  by  line.  In  this  study,  the 
“scripted”  filename  for  the  request  packet  size  was  “NMSlSlReq  pktsize  dist.csv”. 
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Figure  14  Definition  of  Get  request  traffic  parameters  in  ‘Task  Config’  object 

The  Get  request  inter-arrival  time  and  the  number  of  nodes  are  defined  under  the 
‘inter-repetition  time’  and  ‘number  of  repetitions’  attributes,  respectively  (Figure  15),  un¬ 
der  the  ‘Profile  Config’  object  in  OPNET.  As  for  setting  the  required  number  of  nodes, 
for  example,  to  poll  50  nodes,  the  number  of  repetitions  is  set  to  49. 


Figure  15  Definition  of  Get  request  inter-arrival  time  and  number  of  nodes  parame¬ 
ters  in  ‘Profile  Config’  object 
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The  start  time  of  the  first  SNMP  Get  request  is  set  at  30  s.  This  is  to  allow  suffi- 
eient  time  to  elapse  for  dynamie  routing  protoeol  to  build  the  routing  table.  This  is  de¬ 
fined  in  the  ‘Start  Time  Offset’  under  the  applications  in  the  ‘Profile  Config’  object  (Fig¬ 
ure  16). 


Figure  16  Definition  of  SNMP  Get  request  start  time  in  ‘Profile  Config’  object 

With  the  above  attributes  set,  the  SNMP  behavior  can  be  simulated  using  OPNET. 
Different  SNMPvl  network  management  test  scenarios  can  be  generated  by  varying  the 
Get  request  inter-arrival  time  and  number  of  nodes  to  be  managed. 

The  simulation  technique  that  is  used  in  this  study  is  called  the  Discrete-event 
simulation  (DBS).  DBS  models  a  system  dynamically  and  each  packet  data  transfer  is 
modeled  as  a  discrete  event.  It  enables  the  simulation  of  the  specific  application  transac¬ 
tions,  reproduces  the  exact  network  as  well  as  the  detailed  protocol  behavior.  Hence,  it  al¬ 
lows  the  evaluation  of  the  network  and  application  characteristics  and  studies  the  various 
sources  of  delay  that  could  be  experience  in  the  actual  production  network.  Accurate  re¬ 
sults  can  be  obtained  from  this  technique  but  it  is  time  consuming  and  a  large  memory 
will  be  required  [19].  In  this  study,  the  number  of  nodes  required  for  simulation  can  ap¬ 
proach  tens  of  thousands;  therefore  it  is  impractical  to  physically  create  that  large  number 
of  nodes  in  the  network  configuration  as  shown  in  Bigure  13.  To  simplify  the  modeling 
and  reduce  the  simulation  run-times,  the  number  of  nodes  was  simulated  by  sending  mul- 
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tiple  Get  requests  to  a  single  node  (Figure  13)  rather  than  sending  eaeh  request  to  the  ae- 
tual  number  of  nodes. 


D,  TEST  SCENARIOS 

In  order  to  eheek  the  sealability  issues  of  SNMP  polling,  various  test  seenarios  are 
ereated  by  varying  the  number  of  nodes  and  the  request  inter-arrival  times.  All  test  see¬ 
narios  were  performed  using  the  network  eonfiguration  as  in  Figure  13.  The  objeetive  of 
eaeh  test  seenario  was  to  evaluate  the  performanee  metries,  sueh  as  link  throughput,  link 
utilization,  and  queuing  delay,  eolleeted  after  the  simulation. 

These  performanee  metries  were  studied  beeause  throughput  provides  a  good 
measure  for  projeeted  demand  and  potential  performanee-related  problems.  On  the  other 
hand,  utilization  indieates  the  pereentage  of  loading  on  the  link  eapaeity  over  a  speeified 
period  of  time.  Link  utilization  is  defined  as  the  ratio  of  link  throughput  over  link  data 
rate.  When  fine  granularity  is  required,  utilization  will  be  studied  instead  of  throughput. 

Utilization  is  an  important  performanee  metrie  beeause  it  is  elosely  related  to 
network  eongestion  and  response  time.  Typieally,  utilization  is  a  good  indieation  for  po¬ 
tential  bottleneeks  and  area  of  eongestion.  In  addition,  when  the  utilization  inereases,  the 
response  time  will  usually  inerease  exponentially.  Due  to  this  exponential  behavior,  it  is 
important  to  determine  potential  network  eongestion  before  it  gets  out  of  eontrol  [20]. 
Similarly,  queuing  delay  also  provides  a  good  indieation  of  potential  bottleneeks  and  area 
of  eongestion. 

E.  DISCUSSION  OF  SIMULATION  RESULTS 

The  test  seenarios  vary  the  number  of  nodes  and  the  request  inter-arrival  time,  and 
determine  the  optimum  number  of  nodes  for  a  given  polling  interval  (Figure  17).  The  per¬ 
formanee  metries  studied  were  the  link  utilization,  link  throughput  and  queuing  delay. 
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Agent  =1 
Agent  =2 
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Agent  =5 

Agent  =N 


Figure  17  SNMP  polling  showing  polling  interval,  request  inter-arrival  time  and 

number  of  agents 

1,  Effect  of  Varying  the  Number  of  Nodes 

This  experiment  was  designed  to  explore  the  effeets  of  varying  the  number  of 
nodes  for  a  given  request  inter-arrival  time.  The  request  inter-arrival  time  that  is  used  in 
each  scenario  and  the  corresponding  figures  depicting  results  for  each  run  of  the  experi¬ 
ment  are  outlined  in  Table  7. 
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Test  scenarios  no. 

Request  inter-arrival  time 

(fis) 

Figures  depicting  results 

1 

2-1200 

18(a)  &(b) 

2 

2000 

19(a)  &  (b) 

3 

3000 

20(a)  &  (b) 

4 

4000 

21(a)  &(b) 

5 

5000 

22(a)  &  (b) 

Table  7  The  request  inter- arrival  time  used  to  study  the  effect  of  varying  the  num¬ 

ber  of  nodes 


Figures  18  to  22  show  the  link  utilization  and  link  throughput  respectively  ob¬ 
tained  due  to  the  effect  of  varying  the  number  of  nodes  to  be  managed  by  NMS  at  a  given 
request  inter-arrival  time.  Each  figure  consists  of  a  pair  of  graphs.  The  first  graph  shows 
the  plot  of  link  utilization  against  time  taken  to  poll  the  specific  number  of  nodes;  the 
second  graph  shows  the  plot  of  link  throughput  against  time  taken  to  poll  the  specific 
number  of  nodes.  When  the  link  utilization  is  more  than  80%  or  the  link  throughput  is 
more  than  80%  of  the  link  rate,  (as  mentioned  in  Chapter  VI,  Section  C,  link  rate  is  768 
kbps,  i.e.,  the  theoretical  maximum),  processing  bottlenecks  and  network  congestion  will 
likely  occur.  The  link  utilization  and  link  throughput  is  measured  on  the  link  between  the 
NMS  and  router.  The  link  utilization  and  link  throughput  results  obtained  from  the  five 
different  test  scenarios  are  tabulated  in  Table  8  and  9.  From  numerous  simulations,  it  is 
found  that  for  a  given  number  of  nodes  and  for  any  request  inter-arrival  times  of  between 
2  q  s  and  1200  q  s,  the  link  utilization  and  link  throughput  shows  identical  results.  As 
such,  analysis  of  request  inter-arrival  time  of  between  2  qs  and  1200  qs  is  considered  to¬ 
gether.  It  is  observed  that  all  plots  start  at  approximately  30  s,  this  is  expected  as  the  start 
time  of  the  first  Get  request  begins  only  30  s  after  the  simulation  starts  (as  explained  ear¬ 
lier  in  Section  C  of  this  chapter). 


42 


In  general,  link  utilization  and  link  throughput  inerease  with  an  increase  in  the 
number  of  nodes  at  a  given  request  inter-arrival  time.  The  experiment  results  are  as  ex¬ 
pected,  given  that  with  more  nodes  to  be  managed  more  packets  will  be  sent.  Comparing 
the  results  obtained  for  the  five  different  test  scenarios,  it  is  observed  the  link  utilization 
will  only  reach  100%  or  link  throughput  will  equal  link  data  rate  if  the  request  inter¬ 
arrival  time  is  between  2  p  s  and  1200  p  s.  This  will  mean  that  if  the  request  inter-arrival 
time  is  between  2  p  s  and  1200  p  s,  the  DCC  will  likely  experience  bottleneck  or  network 
congestion  if  the  NMS  is  to  manage  200  or  more  nodes.  This  will  likely  affect  the  proper 
operation  of  network  management  function  of  the  NMS. 
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(a) 


(b) 

Figure  18  Screen  shot  of  (a)  link  utilization  and  (b)  link  throughput  depicting  the  ef¬ 
fect  of  varying  the  number  of  nodes  for  any  request  inter-arrival  times  of  between  2  ps  to 

1200ps. 
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(a) 


(b) 


Figure  19  Screen  shot  of  (a)  link  utilization  and  (b)  link  throughput  depicting  the  ef¬ 
fect  of  varying  the  number  of  nodes  for  request  inter-arrival  times  of  2000  p,  s. 
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(a) 


(b) 


Figure  20  Screen  shot  of  (a)  link  utilization  and  (b)  link  throughput  depicting  the  ef¬ 
fect  of  varying  the  number  of  nodes  for  request  inter-arrival  times  of  3000  p.  s. 


46 


(a) 


(b) 


Figure  21  Screen  shot  of  (a)  link  utilization  and  (b)  link  throughput  depicting  the  ef¬ 
fect  of  varying  the  number  of  nodes  for  request  inter-arrival  times  of  4000  q  s. 
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(a) 


(b) 


Figure  22  Screen  shot  of  (a)  link  utilization  and  (b)  link  throughput  depicting  the  ef¬ 
fect  of  varying  the  number  of  nodes  for  request  inter-arrival  times  of  5000  q  s. 
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No.  of 

Link  Utilization  (%)  for  different  request  inter-arrival  time 

Nodes 

2-1200  |us 

2000  qs 

3000  qs 

4000  qs 

5000  qs 

50 

24.38 

24.38 

24.38 

24.38 

24.38 

100 

48.75 

48.75 

40.85 

30.71 

24.38 

150 

73.13 

60.94 

40.85 

30.71 

24.38 

200 

97.50 

60.94 

40.85 

30.71 

24.38 

250 

100 

60.94 

40.85 

30.71 

24.38 

Table  8  Link  utilization  due  to  the  effeet  of  varying  the  number  of  nodes  to  be 

managed  at  a  given  request  inter-arrival  times 


No.  of 

Link  Throughput  (kbps)  for  different  request  inter-arrival  time 

Nodes 

2-1200  qs 

2000  qs 

3000  qs 

4000  qs 

5000  qs 

50 

187.2 

187.2 

187.2 

187.2 

187.2 

100 

374.4 

374.4 

313.8 

235.9 

187.2 

150 

561.6 

468 

313.8 

235.9 

187.2 

200 

748.8 

468 

313.8 

235.9 

187.2 

250 

768 

468 

313.8 

235.9 

187.2 

Table  9  Link  throughput  due  to  the  effeet  of  varying  the  number  of  nodes  to  be 
managed  at  a  given  request  inter-arrival  times 
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The  corresponding  queuing  delay  is  shown  in  Figure  23.  This  figure  shows  that 
the  queuing  delay  for  200  or  more  nodes  is  at  least  121.5  ms  and  will  increase  with  an  in¬ 
crease  in  the  number  of  nodes.  This  result  is  expected  because  the  packets  at  the  router 
will  build  up  much  more  quickly  when  there  are  many  packets  being  sent  within  a  short 
inter-arrival  time.  In  other  words,  for  a  request  inter-arrival  time  of  between  2|us  and 
1200  ps,  in  order  to  avoid  a  bottleneck,  it  is  necessary  for  the  NMS  to  manage  not  more 
than  200  nodes. 

Based  on  the  link  utilization  or  link  throughput  results,  for  request  inter-arrival 
times  of  above  2000  ps,  the  link  utilization  is  less  than  50%.  Hence,  the  number  of  nodes 
to  be  managed  by  the  NMS  will  not  be  constrained  by  queuing  delay  or  network  conges¬ 
tion. 
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Figure  23  Screen  shot  of  queuing  delay  depicting  the  effect  of  varying  the  number  of 
nodes  for  any  request  inter-arrival  times  of  between  2  q  s  to  1200  q  s. 


2,  Variation  of  Request  Inter-arrival  Times 

This  experiment  was  designed  to  explore  the  effects  of  varying  the  request  inter¬ 
arrival  time  (from  2  q  s  to  5000  q  s)  for  a  given  number  of  nodes  to  be  managed  by  the 
NMS.  The  assumption  made  in  this  experiment  is  that  the  minimum  request  inter-arrival 
time  will  not  be  less  than  2  q  s  and  the  maximum  request  inter-arrival  time  will  not  ex¬ 
ceed  5000  qs.  In  this  experiment,  we  assume  that  450  nodes  are  to  be  managed  by  the 
NMS. 
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Figures  24  (a)  and  (b)  show  the  link  utilization  and  link  throughput  respeetively 
obtained  due  to  the  effeet  of  varying  the  request  inter- arrival  time  when  450  nodes  are  be¬ 
ing  managed  by  NMS.  The  link  utilization  and  link  throughput  results  obtained  from  this 
test  seenario  are  tabulated  in  Table  10. 

In  general,  to  manage  450  nodes,  link  utilization  deereases  with  an  inerease  in  the 
request  inter-arrival  time.  The  experimental  results  are  as  expeeted,  given  that  with  the 
higher  request  inter-arrival  time,  more  time  is  given  to  the  router  to  proeess  eaeh  paeket 
sent,  henee  the  ehanee  of  bottleneek  or  network  eongestion  is  redueed.  This  ean  be  seen 
in  Table  10  where  the  link  utilization  is  lower  for  request  inter- arrival  times  of  above 
1220  |us  beeause  the  request  inter-arrival  time  is  large  enough  for  the  router  to  proeess  the 
ineoming  paekets  before  the  queue  build  up.  Based  on  numerous  simulations,  it  was 
found  that  the  link  utilization  and  link  throughput  for  the  different  request  inter-arrival 
times  as  listed  in  Table  10  are  the  maximum  aehievable  value.  In  addition,  it  ean  be  seen 
from  Table  8  and  9  that,  in  faet,  this  maximum  value  will  be  reaehed  when  the  NMS  is  to 
manage  250  nodes.  Table  10  shows  that  for  a  link  utilization  of  less  than  80%,  it  is  better 
to  use  a  request  inter- arrival  time  of  more  than  1500  p,  s  in  order  to  effeetively  manage 
450  nodes. 
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(a) 


~*~l  Throughput  of  different  request  inter-arrival  times  @  450  nodes  Ifb  IfX  | 


■  2us_1 200uslAT 450nodes 

■  1 21 0uslAT450nodes 

■  1220uslAT450nodes 

1 500uslAT_450nodes 
2000uslAT_450nodes 

■  2500uslAT_450nodes 
3000uslAT_450nodes 
3500uslAT_450nodes 
4000uslAT_450nodes 
4500uslAT_450nodes 
5000uslAT_450nodes 


...  Om  29s  Om  30s  Om  31s  Om  32s  Om  33s 


(b) 

Figure  24  Screen  shot  of  (a)  link  utilization  and  (b)  link  throughput  depicting  the  ef¬ 
fect  of  varying  the  request  inter-arrival  times  when  managing  450  nodes. 
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Request  inter-arrival  times 

(qs) 

Link  Utilization 

(%) 

Link  Throughput 

(kbps) 

2-1200 

100 

768 

1210 

100 

768 

1220 

99.90 

767.2 

1500 

81.32 

624.5 

2000 

60.94 

468 

2500 

48.75 

374.4 

3000 

40.85 

313.8 

3500 

35.10 

269.6 

4000 

30.71 

235.9 

4500 

27.30 

209.7 

5000 

24.38 

187.2 

Table  10  Link  utilization  and  throughput  against  different  request  inter-arrival  times 

when  managing  450  nodes. 

Figure  25  shows  for  a  request  inter- arrival  time  of  1210  q  s,  with  450  nodes  to  be 
managed,  the  queuing  delay  is  inereasing  at  a  mueh  slower  rate  as  eompared  to  the  queu¬ 
ing  delay  for  any  request  inter-arrival  times  of  between  2  q  s  to  1200  q  s.  However,  for 
any  request  inter-arrival  time  of  1220  qs  and  above,  the  queuing  delay  is  eonstant  at  1.22 
ms  and  is  negligible.  Therefore,  for  any  request  inter-arrival  times  of  1220 qs  and  above, 
the  number  of  nodes  that  ean  be  managed  will  only  be  limited  by  the  polling  interval  in¬ 
stead  of  constrained  by  the  bottleneck  or  congestion  level  in  the  network  (this  will  be  ex¬ 
plained  in  more  detail  later).  Since  all  plots  for  a  request  inter-arrival  time  of  1220  qs  and 
above  have  the  same  queuing  delay  and  the  first  poll  starts  at  30s  for  all  simulations,  plots 
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for  request  inter-arrival  time  of  1220  q  s  and  above,  depending  on  the  inter- arrival  time, 
will  either  fully  or  partially  overlap  the  previous  plot,  as  shown  in  Figure  25. 


Figure  25  Screen  shot  of  queuing  delay  depicting  the  effect  of  varying  the  request  in¬ 
ter-arrival  times  when  managing  450  nodes. 
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3,  Polling  Interval 

The  polling  interval  is  an  important  parameter  as  it  determines  how  often  the 
management  station  will  have  an  up-to-date  view  of  the  network.  As  sueh,  some  form  of 
poliey  must  be  in  plaee  to  determine  the  frequency  with  which  the  management  station 
polls.  Though  performance  is  dependent  on  the  processing  power  in  the  management  sta¬ 
tion,  level  of  congestion,  and  other  performance-related  factors,  the  main  deciding  factor 
on  the  specification  of  the  polling  interval  is  the  size  of  the  network.  In  other  words,  it  is 
the  number  of  agents  that  are  to  be  effectively  managed  by  the  management  station  will 
directly  affect  the  polling  interval  specified.  In  order  to  provide  a  quick  indication  on  the 
maximum  number  of  agents  a  network  can  support,  some  simple  formulas  must  be  cre¬ 
ated.  This  problem  can  be  simplified  by  considering  that  only  one  agent  can  be  managed 
by  the  management  station  at  a  time  and  the  management  station  is  engaged  full-time  in 
polling.  The  poll  may  involve  either  one  or  more  Get  transactions.  Based  on  the  above 
assumptions,  the  following  equation  is  generated  [20]. 


where 


N=  Number  of  agents, 

T  =  Polling  interval,  and 
A  =  processing  time  to  generate  a  request. 


(6.1) 


The  above  equation  is  a  slight  modification  of  a  similar  formula  as  specified  in 
Reference  [20].  In  Reference  [20],  the  author  considers  the  processing  time  for  both  re¬ 
quest  and  response;  in  our  case,  we  only  assume  the  processing  time  for  the  request, 
which  is  the  request  inter- arrival  time. 

Assuming  a  polling  interval  of  30  s  and  using  the  minimum  request  inter-arrival 
time  of  733  ps  (worst  case)  obtained  from  the  traffic  analysis,  the  theoretical  maximum 

number  of  agents  that  the  NMS  can  manage  is  A  <  41,000.  Hence,  as  discussed  in  the 
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Sub-section  1  of  this  section  (effect  of  variation  of  number  of  nodes),  for  a  request  inter¬ 
arrival  time  of  733  q  s,  the  number  of  nodes  that  the  NMS  can  effectively  manage  should 
not  exceed  200  nodes.  In  addition,  as  observed  from  the  traffic  analysis,  the  NMS  can 
poll  a  single  agent  multiple  times  within  a  polling  interval  for  different  statistics.  There¬ 
fore,  the  effective  number  of  nodes  that  can  be  managed  will  be  lower. 

4,  Optimum  Number  of  Nodes  for  a  Given  Polling  Interval 

This  experiment  is  based  on  the  assumption  that  the  polling  interval  is  30  s  and  an 
acceptable  maximum  queuing  delay  is  135  ms.  For  plot  with  a  request  inter-arrival  time 
of  1210  |u  s  and  different  number  of  nodes,  the  queuing  delay  is  increasing  at  the  same 
rate.  Since  the  first  poll  starts  at  30  s  for  all  simulations,  plots  for  request  inter- arrival 
time  of  1210  p  s  with  different  number  of  nodes  will  partially  overlap  by  the  previous 
plot,  as  shown  in  Figure  26.  Based  on  the  earlier  simulation  results  when  the  number  of 
nodes  is  varied,  the  maximum  number  of  nodes  that  can  be  managed  without  experienc¬ 
ing  significant  bottleneck  for  any  request  inter- arrival  times  of  between  2  p  s  to  1200  p  s  is 
approximately  200  nodes.  This  will  give  a  queuing  delay  of  approximately  121.5  ms. 
Figure  26  shows  that  the  queuing  delay  goes  up  to  approximately  132.4  ms  when  the 
number  of  nodes  is  increased  to  15,000  nodes  at  a  request  inter- arrival  time  of  1210  ps. 

As  such,  based  on  the  acceptable  maximum  queuing  delay  assumed,  the  optimum  number 
of  nodes  for  a  request  inter-arrival  time  of  1210  p  s  is  approximately  15,000  nodes.  Be¬ 
yond  a  request  inter- arrival  time  of  1210 ps,  the  maximum  possible  queuing  delay  is  ap¬ 
proximately  1 .22  ms  and  is  negligible;  as  such,  the  optimum  number  of  nodes  is  deter¬ 
mined  by  using  Equation  (6.1). 
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Figure  26  Screen  shot  of  queuing  delay  for  different  request  inter-arrival  time  and 

different  number  of  nodes 


Based  on  the  above,  the  optimum  number  of  nodes  for  different  request  inter¬ 
arrival  times  is  tabulated  in  Table  11.  These  data  points  are  plotted  in  Figure  27  and  these 
data  points  are  merely  joined  up  by  a  straight  line.  Figure  27  can  be  divided  into  2  zones, 
the  “bottleneck  zone”  and  the  “non-congestion  zone”. 
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Optimum  number  of  nodes 

Request  inter-arrival  time  ( p  s) 

200 

2-1200 

15000 

1210 

24590 

1220 

23077 

1300 

20000 

1500 

15000 

2000 

6000 

5000 

Table  1 1  Optimum  number  of  nodes  for  different  request  inter- arrival  times  with  a 
polling  interval  of  30  s  and  a  maximum  aeeeptable  queuing  delay  of  135  ms 

a,  “Bottleneck  Zone” 

This  zone  is  defined  between  request  inter-arrival  times  of  2  p,  s  to 
1210  ps.  In  this  zone,  a  bottleneek  will  be  experieneed  due  to  the  high  rate  of  requests  be¬ 
ing  sent,  espeeially  for  a  large  number  of  nodes.  Henee  in  this  zone,  the  optimum  number 
of  nodes  that  the  NMS  ean  effeetively  manage  depends  largely  on  the  aeeeptable  queuing 
delay  or  aeeeptable  eongestion  level  of  the  network.  Figure  27  shows  that  the  number  of 
nodes  that  ean  be  managed  is  constant  from  2  p  s  to  1200  p  s.  However,  there  is  a  sharp 
increase  in  the  number  of  nodes  that  can  be  managed  from  1200  psto  1210ps.  This  in¬ 
crease  is  dependent  on  the  queuing  delay  that  one  specifies  or  can  tolerate.  If  a  higher 
queuing  delay  can  be  tolerated,  the  curve  will  increase  more  gradually  from  a  request  in¬ 
ter-arrival  time  starting  from  2  ps. 
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b.  “Non-congestion  Zone” 

This  zone  is  defined  for  a  request  inter-arrival  time  of  more  than  1210|us. 
In  this  zone  the  optimum  number  of  nodes  that  the  NMS  can  effectively  manage  is  con¬ 
strained  by  the  polling  interval  specified.  For  a  request  inter-arrival  time  of  1210  p  s  and 
below,  the  optimum  number  of  nodes  is  not  dependent  on  the  polling  interval.  On  the 
other  hand,  for  a  request  inter- arrival  time  of  above  1210  p  s,  the  optimum  number  of 
nodes  will  increase  with  an  increase  in  the  polling  interval  as  seen  from  Equation  (6.1). 


Figure  27  Optimum  number  of  nodes  to  be  effectively  managed  for  different  request 
inter-arrival  times  with  a  polling  interval  of  30  s  and  a  maximum  acceptable  queuing  de¬ 
lay  of  135  ms. 
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F.  CONCLUSIONS 

This  chapter  presented  the  modeling  of  SNMP  using  OPNET,  based  on  the  statis- 
ties  obtained  from  the  traffie  analysis  on  the  measured  SNMP  traffic  fitted  to  the  eon- 
straints  of  an  optieal  network  management  ehannel.  It  outlined  the  test  seenarios  used  for 
the  simulation.  This  ehapter  looked  at  the  effeets  of  altering  the  SNMP  traffie  parameters. 
There  were  three  sets  of  experiments  eondueted  -  the  effeet  of  varying  the  number  of 
nodes  and  request  inter-arrival  times,  and  finding  the  optimum  number  of  nodes  to  be 
managed  for  a  speeified  polling  interval  were  explored.  The  simulation  results  were  pre¬ 
sented  and  diseussed  for  the  study  of  the  sealability  issues  of  SNMP -based  polling  over 
SONET/SDH  networks. 

The  next  ehapter  summarizes  the  findings  from  this  study  and  presents  possible 
areas  for  future  work. 
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VII  SUMMARY  AND  FUTURE  WORK 


A.  CHAPTER  OVERVIEW 

This  chapter  provides  a  summary  of  the  findings  of  this  study.  Ineluded  in  the 
summary  are  eonelusions  from  observations  made  during  the  exeeution  of  this  study. 
Suggestions  for  future  and  follow-on  work  are  also  presented. 


B,  SUMMARY 

Undertaking  this  thesis  projeet  has  provided  the  author  with  many  learning  oppor¬ 
tunities  regarding  the  network  management  and  its  assoeiated  technologies.  The  first  part 
of  this  study  involved  performing  a  traffie  analysis  on  measured  SNMP  traffie  to  develop 
statisties  needed  to  model  the  traffie.  This  analysis  is  neeessary  in  understanding  the  traf¬ 
fie  parameters,  sueh  as  polling  interval,  request  inter-arrival  times,  request  paeket  size, 
ete.,  of  an  aetual  SNMP  traffie.  With  the  understanding  of  the  SNMP  traffie,  SNMPvl 
model  was  defined  and  integrated  into  an  OPNET  network  model  to  study  the  sealability 
issues  of  SNMP -based  polling. 

Subsequently,  various  test  seenarios  are  generated  and  simulated.  The  perform- 
anee  of  SNMP  was  studied  with  respeet  to  the  effeet  of  varying  the  number  of  nodes  and 
request  inter-arrival  times,  and  obtaining  an  optimum  number  of  nodes  for  a  speeified 
polling  interval. 

In  exploring  the  effeet  of  varying  the  number  of  nodes  to  be  managed  by  the 
NMS,  it  was  determined  that,  for  a  given  request  inter- arrival  time,  the  link  utilization 
and  link  throughput  would  inerease  with  an  inerease  in  the  number  of  nodes  to  be  man¬ 
aged.  From  the  simulation  results,  potential  bottleneeks  and  the  level  of  eongestion  in  the 
network  eould  be  determined.  Henee,  the  allowable  number  of  nodes  that  eould  be  effee- 
tively  managed  by  a  NMS  at  a  speeifie  request  inter-arrival  time  eould  be  determined 
from  the  results  obtained. 

In  exploring  the  effeet  of  varying  the  request  inter-arrival  time,  it  was  determined 
that,  for  a  given  number  of  nodes,  the  link  utilization  and  link  throughput  would  deerease 
for  an  inerease  in  request  inter-arrival  time.  From  the  simulation  results,  given  the  num- 
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ber  of  nodes  to  be  managed,  an  appropriate  request  inter-arrival  time  eould  be  deter¬ 
mined. 

Additionally,  for  a  given  polling  interval,  results  were  obtained  on  determining 
the  optimum  number  of  nodes  that  a  NMS  ean  effeetively  manage  for  different  request 
inter-arrival  time  without  any  signifieant  bottleneek  or  network  eongestion.  From  this 
analysis,  two  different  zones,  i.e.,  the  “bottleneek  zone”  and  the  “non-eongestion  zone”, 
were  defined.  In  the  “bottleneek  zone”,  the  number  of  nodes  that  eould  be  managed  was 
signifieantly  lower  than  those  in  the  “non-eongestion  zone”.  However,  in  the  “non¬ 
congestion  zone”  the  number  of  nodes  that  could  be  managed  was  limited  by  the  polling 
interval. 

B,  FUTURE  WORK 

Throughout  this  study,  a  number  of  possible  directions  have  been  identified  for 
future  work  and  they  are  as  follows: 

1.  OPNET  Modeler 

In  the  OPNET  IT  GURU,  a  virtual  network  environment  is  created  from  the  in¬ 
formation  one  has;  coarse  granularity  (minimum  detail)  is  required  for  the  modeling.  In 
this  study,  the  OPNET  IT  GURU  is  sufficient  to  provide  us  a  quick  estimate  on  the  per¬ 
formance  of  SNMP  in  an  optical  network  with  respect  to  its  scalability.  In  order  to  obtain 
a  more  exact  result,  SNMP  can  be  modeled  more  exactly  by  using  the  OPNET  Modeler. 
In  the  OPNET  Modeler,  fine  granularity  (more  detail)  is  required  to  allow  greater  preci¬ 
sion;  hence  this  will  require  more  complex  development.  With  the  OPNET  Modeler,  one 
can  reproduce  the  SNMP  traffic  behavior  exactly  and  the  protocol  specifications  can  be 
defined  and  created  in  OPNET  Modeler. 

2,  Generate  Real  SNMP  Traffic  in  Network  Testbed 

A  test  network  can  be  setup  in  the  laboratory  and  the  network  management  tool 
can  be  installed  into  the  network  testbed  to  provide  realistic  SNMP  traffic.  The  test  sce¬ 
narios  generated  in  this  study  could  be  reproduced  and  results  obtained  from  the  network 
testbed  compared  with  the  OPNET  analysis  performed  in  this  study. 
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3,  Security  Issues  in  SNMP 

Security  is  a  major  concern  in  most  networks.  With  the  development  of  SNMPv3, 
security  features  such  as  authentication,  access  control  and  encryption  were  added  to 
SNMPv3.  With  this  new  development,  a  study  could  be  conducted  to  verify  the  robust¬ 
ness  of  these  security  features  and  how  secure  management  data  can  be  in  network  with 
the  implementation  of  SNMPv3.  In  addition,  a  study  could  also  look  at  other  possible  se¬ 
curity-related  issues  even  with  the  implementation  of  SNMPv3. 

4,  Using  a  Mobile  Agent  for  Distributed  Network  Management 

There  are  numerous  problems  that  a  centralized  client-server  based  network  man¬ 
agement  frameworks  have  suffered  such  as  insufficient  scalability,  interoperability,  reli¬ 
ability  and  low  flexibility.  As  such,  there  is  a  moving  trend  towards  distributed  network 
management,  i.e.  to  disperse  or  distribute  centralized  network  management.  Today’s  rap¬ 
idly  changing  distributed  network  environment  has  caused  network  management  to  be¬ 
come  a  critical  issue  .  Since  then,  several  new  enabling  technologies  for  distributed  net¬ 
work  management  have  been  developed  and  one  such  technology  is  the  Mobile  agent.  It 
is  a  rapidly  developing  area  of  research  in  the  fields  of  network  management.  In  order  to 
handle  today’s  rapidly  changing  and  complex  networks,  mobile  agents  are  used  in  the 
management  of  network  systems  to  enhance  management  distribution  and  distribute  the 
management  functionality  throughout  the  network  [5,9].  Hence,  it  may  be  useful  to  study 
the  performance  of  network  management  using  mobile  agent. 
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